REMARKS 

Claims 1 and 17 have been amended. No new matter has been introduced with these 
amendments, all of which are supported in the application as originally filed. Claims 1, 3, 5, 7, 9 - 
13, and 17 remain in the application. 

Applicant is not conceding that the subject matter encompassed by the claims as presented 
prior to this Amendment is not patentable over the art cited by the Examiner, and claim 
amendments and cancellations in the present application are directed toward facilitating 
expeditious prosecution of the application and allowance of the currently-presented claims at an 
early date. Applicant respectfully reserves the right to pursue claims, including the subject matter 
encompassed by the claims as presented prior to this Amendment and additional claims, in one or 
more continuing applications. 

I. Rejection under 35 U.S.C. 3103(a) 

Paragraph 4 of the Office Action dated July 28, 2008 (hereinafter, "the Office Action") 
states that Claims 1, 3, 5, 9 - 13, and 17 are rejected under 35 U.S.C. § 103(a) as being obvious 
over "Resource Description Framework (RDF) Model and Syntax Specification" (hereinafter, 
"RDF Syntax") in view of U. S. Patent 6,654,759 to Brunet. This rejection is respectfully 
traversed. 



At the outset, Applicant respectfully notes that the rejections in the Office Action fail to 
state what part of a cited text passage or figure is being relied on, or how any part of that text 
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passage or figure is being interpreted by the Examiner, when discussing Applicant's claim 
language. This provides Applicant with no guidance for formulating a response to the rejection. 
Accordingly, Applicant has been left to guess as to what the Examiner is actually citing, and how 
that has been interpreted. Any continuing disagreement between Applicant and the Examiner as 
to whether a claim limitation is taught by the references is therefore a direct result of the lack of 
specificity in the Office Action. 

Furthermore, Applicant respectfully submits that this approach to analyzing his claim 

language in the Office Action is legally deficient , as it does not meet the requirements laid out in 

37 CFR 1.104, "Nature of Examination", which states in paragraph (c)(2), 

In rejecting claims for ... obviousness, the examiner must cite the best 
references at his or her command. When a reference is complex or shows or 
describes inventions other than that claimed by the applicant, the particular part 
relied on must be designated as nearly as practicable . The pertinence of each 
reference, if not apparent, must be clearly explained ... (emphasis added) 

Referring first to Applicant's independent Claim 1, when analyzing the "defining ..." claim 
element recited on lines 7 - 9 of Claim 1, the Office Action cites RDF Syntax, Section 2.2, para. 2 
for the "defining, in the class definition of a topmost class of the hierarchical schema, a naming 
rule property and an instance identity property" claim language on lines 7-8. Office Action, 
para. 4, lines 16 - 18. This analysis in the Office Action merely states "XML rules", with no 
further discussion of how "XML rules" supposedly disclose a naming rule property and an 
instance identity property. Applicant notes that the cited text discusses "XML rules" in terms of 
the need to "exactly match" the names in start tags (i.e., tags enclosed in "<" and ">") with the 
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names in end tags (i.e., tags enclosed in "</" and ">"). Applicant fails to see any relevance of this 
discussion to his claim language as recited on lines 7 - 8 of Claim 1 . 

The Office Action then cites RDF Syntax, Section 1 , para. 5 for the "wherein each class at 
levels of the hierarchical schema beneath the topmost class inherits the naming rule property and 
the instance identity property" claim language on lines 8 - 9 of Claim 1 . Office Action, p. 3, last 
line - p. 4, lines 1-2. The Office Action fails to indicate where this cited text supposedly 
discusses anything pertaining to a naming rule property and an instance identity property . 

The Office Action admits that RDF Syntax does not disclose Applicant's claim language 
as recited on lines 10 - 30 of Claim 1. Office Action, p. 4, line 3 - p. 5, line 4. Brunet is then 
cited. Applicant disagrees with the analysis of Brunet, as will now be discussed. 

With regard to the "specifying a value ..." claim element recited on line 10 of Claim 1, 
Applicant notes that the Office Action fails to cite any reference as teaching this claim element. 
The Office Action therefore fails to make out a prima facie case of obviousness with regard to 
Claim 1 . Notably, this claim element recites that the value is specified in the class definition. So, 
for example, if the naming rule property for Organization class 120 of Fig. 1 has as its property 
value "DomainName", as stated at 210 of Fig. 2, then the class definition for Organization class 
includes a property with a name such as '^amingRule", and that property has (for the 
Organization class) a value of "DomainName". The naming rule property , in this example, may 
then be described as follows: 
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(See p. 28, lines 5 
discussed.) 



NamingRule = DomainNamc 
- 6 et seq. of Applicant's specification, where the naming rule in this example is 



With regard to the "for each class definition, the selected at least one property name is 
selected to ensure that each instance identity generated for the instances defined according to the 
class definition is unique among all of the instances in the hierarchical schema " claim language 
recited on lines 13 - 15 of Claim 1 (emphasis added), the office Action cites col. 7, line 30 of 
Brunet. Office Action, p. 5, lines 11-14. Applicant respectfully submits that the cited portion of 
Brunet must be considered in its entirety, noting that the discussion of uniqueness states " based 
on a hierarchical order "; see col. 7, line 32, emphasis added. See also: 

• col. 7, lines 35 - 39, stating "... the naming attribute being the attribute that, in the 

class, allows the unique identification ... of an instance relative to its mother [i.e., 

parent] instance " (emphasis added); and 

col. 7, lines 43 - 46, stating "Each instance ... is uniquely identified by its 
distinguished name DN , which is the sequence of names RDN on the path between 
the root and the instance in the instance tree" (emphasis added). 

In other words, Brunet states that the uniqueness is obtained by the full distinguished 
name , which - as is known in the art, and acknowledged by the above-cited portions of Brunet - 
is formed as the sequence of names for each of the nodes on a particular path. This is in sharp 
contrast to Applicant's claim language, which recites that the instance identity "is unique among 
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all of the instances in the [entire] hierarchical schema " (Claim 1, lines 14 - 15, emphasis added). 
Note also that this unique instance identity is specified as the value of the instance identity 
property of each instance, according to Claim 1, lines 21 -25. (For example, the instance 300 of 
Organization class, which is illustrated in Fig. 3A, would include an additional property with a 
property name such as "InstancelD", and the value of this instance ID property is shown in Fig. 
3B. See the text on p. 28, lines 1 1 - 14 of Applicant's specification, beginning with 
"Accordingly" and ending with "as was discussed earlier".) This is in contrast to Brunet's 
distinguished name approach, where a unique identity of a particular node is constructed using 
assertion AVAs from each of the nodes on a path from the root node to the particular node. 

An example illustrating how Applicant's claimed approach differs from that of Brunet can 
be seen with reference to Applicant's Figs. 1, 2, and 6A - 6B. As shown in Fig. 1, "Server" class 
160 is a child class of "Application" class 150. Reference number 240 in Fig. 2 indicates that the 
naming rule for "Server" class specifies only "URL". That is, the value of a server's URL is 
sufficient to uniquely identify that server. See Fig. 6A, where sample property values are 
illustrated for a hypothetical server instance. (See also p. 30, lines 17-19 and p. 31, lines 1-10, 
where this is discussed.) Fig. 6B shows the instance identity for that server instance, where this 
instance identity has been created according to the naming rule at 240 in Fig. 2. 1 (The instance 

x See the paragraph on p. 9, line 17 - p. 10, line 5 of Applicant's specification, which states 
"Instance identities ... are structured strings. For a particular resource, this structured string is created 
using the naming rules of the class to which the resource belongs. See also the paragraph on p. 10, 
lines 10 - 16, stating "... When it is desirable to access a resource, its naming rule is looked up [i.e., the 
naming rule for the class associated with that resource], and the resource's natural properties are used to 
construct the resource's identity according to that naming rule. Page 25, lines 17 - 19 state "... the 
instance's identity can then be constructed from the naming rule for that instance's class and the instance's 
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identity also specifies the class name "Server", as discussed at p. 19, line 18 and p. 20, line 3.) 



By contrast, the approach used by Brunet would form an identity for this hypothetical 
server by including a name/value pair from each parent node of the server in the resource 
hierarchy. With reference to the sample hierarchy in Applicant's Fig. I, for example, this 
approach of Brunet would require the server instance from Fig. 6A to include a name/value pair 
from the parent Application class 160, as well as name/value pairs for parent classes 110, 130. 

See also the definition of "distinguished name" 2 and "relative distinguished name" 3 found 
on the Internet at OpenDS Wiki, which refer to building a distinguished name by appending 
relative distinguished name components. 

With regard to the claim language recited on lines 19 - 20 of Claim 1, the Office Action 
cites col. 7, line 30 of Brunet. Office Action, p. 5, lines 18-19. Applicant notes that this text of 
Brunet discusses "uniquely" identifying an instance, but respectfully submits that this discussion is 
in terms of constructing a unique name using a full distinguished name , as has been discussed 
above with regard to lines 13 - 15 of Claim 1. 



properties.". In other words, a particular class specifies a naming rule, and this naming rule is used to 
create an identity for each instance of that class (by using property values of that instance). 

2 See https://www.opends.org/wiki/page/DefinitionDistinguishedName. 

3 See https ://www. opends.org/wiki/page/DefinitionRelativeDistinguishedName. 
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With regard to the claim language recited on lines 26 - 30 of Claim 1, the Office Action 
cites col. 7, lines 35 - 36 of Brunet. Office Action, p. 6, lines 4 - 10. Applicant respectfully 
submits that the cited text fails to disclose (at least) "the value of the instance identity specifies a 
class name and ... a name and value pair in contrast to the recitations on lines 26 - 30 of 
Claim 1 (emphasis added). See, for example, Applicant's Fig. 3B, where the value of an instance 
ID is shown at 350 as "Organization(DomainName="ibm.com")". From this sample "value of the 
instance identity" (Claim 1, line 26), the "class name of a particular one ..." Claim 1, line 26) is 
Organization; the "name and value pair" (Claim 1, line 29) is DomainName= "ibm.com ". Note 
that Fig. 3B does not specify the property name that corresponds to this property value 350; the 
property name might be InstancelD, for example, in which case the property may be described as 
follows: 

InstancelD = Organization(DomainName="ibm.com") 
Applicant respectfully submits that Brunet has no teaching, or any suggestion, of specifying the 
class name , along with name and value pair , for the "value of the instance identity" as recited by 
Applicant on lines 26 - 30 of Claim 1. 

In view of the above, Applicant respectfully submits that the cited references fail to teach, 
or suggest, all of the claim elements of Claim 1, in contrast to the assertions in the Office Action. 
Independent Claim 1 is therefore deemed patentable over RDF Syntax and Brunet, whether taken 
singly or in combination (assuming, arguendo, that such combination could be made and that one 
of skill in the art would be motivated to attempt it). Dependent Claims 3,5,7, and 9 - 13 are 
deemed patentable at least by virtue of the patentability of Claim 1 from which they depend. 
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Referring next to independent Claim 17, Applicant respectfully notes that the Office 
Action analysis of this claims refers to "the remarks and discussions made [with regard to] claim 
1". Office Action, p. 8, last 4 lines. Applicant therefore respectfully submits that the same 
arguments presented above with regard to Claim 1 apply in an analogous manner to distinguish 
Claim 17 from RDF Syntax and/or Brunet, and Claim 17 is therefore deemed patentable over 
these references. 

In view of the above, the Examiner is respectfully requested to withdraw the §103 
rejection of all claims as currently presented. 

II. Conclusion 

Applicant respectfully requests reconsideration of the pending rejected claims, withdrawal 

of all presently outstanding rejections, and allowance of all remaining claims at an early date. 

Respectfully submitted, 

/Marcia L. Doubet/ 

Marcia L. Doubet, 
Attorney for Applicant 
Reg. No. 40,999 

Cust. Nbr. for Correspondence: 43168 
Phone: 407-343-7586 
Fax: 407-343-7587 
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